Cálculo de contraste en radio buttons y checkboxes
Esta página explica cómo decide la herramienta si un control de formulario se ve lo suficiente, y dónde esa decisión es frágil. Para la lista de qué controles se cubren y cómo leer un reporte, ver Contraste de elementos activos.
Qué se está midiendo
Esta revisión va sobre la forma del control en sí, no sobre un ícono que tenga dentro.
Un checkbox es un cuadradito. Un radio button es un círculo pequeño. Un campo de texto vacío es un rectángulo. Si el contorno de esa forma —o su relleno— es demasiado pálido, el usuario no puede saber que hay algo ahí para pulsar.
Un ejemplo real: un formulario de contacto con un campo Provincia que no tiene texto de placeholder y sí un borde gris muy claro (#c8c8c8) sobre blanco, midiendo alrededor de 1.67:1. Para muchos usuarios simplemente parece página en blanco; nunca se enteran de que hay un campo que rellenar.
Cómo funciona la medición
1. Reunir los candidatos. Checkboxes, radio buttons y sliders nativos; cualquier cosa marcada como checkbox, radio, barra de progreso o slider; cualquier cosa que lleve un estado de marcado; campos de texto vacíos sin placeholder ni valor; y desplegables que no muestran texto visible.
2. Descartar lo que no cuenta. Los controles deshabilitados se omiten — el estándar los exime explícitamente. Todo lo que esté oculto, transparente, desplazado fuera de la pantalla o recortado a nada se omite.
3. Encontrar el cuadradito real. Esta es la parte delicada. En los sitios modernos el checkbox real suele estar oculto y lo que uno ve en realidad es un elemento decorado. Así que la herramienta primero busca hacia afuera un contenedor visible, y después hacia adentro el elemento pequeño que lleva un borde visible — "ese es el cuadrado que ve el usuario". Todo lo que sea bastante más grande que un checkbox se descarta, asumiendo que no puede ser el indicador.
4. Aplicar el filtro de estilos por defecto. Si la hoja de estilos del propio sitio nunca toca la apariencia, el borde, el fondo ni la sombra del control, el control se omite por completo. El razonamiento: esto lo dibujó el navegador, no es una decisión de diseño del sitio. Esta es la regla más importante que hay que entender de esta revisión — ver las limitaciones más abajo.
5. Medir. La herramienta observa el control más un pequeño margen alrededor y determina tres colores: lo que hay fuera del control, el color de su contorno, y lo que hay dentro. Imagina verter agua desde los bordes: el agua se detiene en el contorno, y lo que no alcanzó es el interior.
- Para un control sin marcar la pregunta es ¿se distingue el control de la página? — comparando dentro contra fuera, y contorno contra fuera, y quedándose con el mejor de los dos.
- Para un control marcado la pregunta es otra: ¿se ve la marca o el punto? — comparando la marca contra el fondo que tiene justo detrás.
6. Decidir. Por debajo de 3:1 el control se reporta. Pero antes de darlo por fallido, la herramienta le concede varias segundas oportunidades: vuelve a comparar contra el color de borde exacto de la hoja de estilos, y luego contra el color de fondo real del contenedor más cercano. Solo reporta un fallo cuando todos esos intentos siguen por debajo de 3:1.
Qué cubre bien
- Checkboxes, radio buttons y sliders nativos que el sitio ha estilizado por su cuenta.
- Implementaciones personalizadas de checkbox y radio, incluido el patrón habitual de "ocultar el input real y decorar un elemento hermano".
- Barras de progreso y sliders.
- Campos de texto, áreas de texto y desplegables vacíos — el caso de Provincia de arriba.
- Ambos estados: la caja vacía y si la marca o el punto dentro de una caja marcada se ve.
- Exime correctamente los controles deshabilitados e ignora correctamente los ocultos.
Limitaciones conocidas
- Todo lo que dibuja el navegador por defecto se omite. Un checkbox o un campo de texto sin estilizar nunca se revisa, aunque el gris propio del navegador sea genuinamente difícil de ver. Es una decisión de producto deliberada, no un bug — pero es una brecha de cobertura, y es la primera que habría que revisar si el equipo decide que esos casos sí deberían reportarse.
- El filtro pregunta "¿lo mencionó la hoja de estilos?", no "¿parece el estilo por defecto?" Un control estilizado para verse exactamente como el del navegador sí se revisa, mientras que un control por defecto pasa gratis. Es una regla práctica, no una comparación visual.
- Los campos con placeholder o con un valor previo se omiten, igual que los desplegables que muestran la etiqueta de una opción — el razonamiento es que el texto visible ya le indica al usuario que el campo existe. Así que un borde de bajo contraste alrededor de un campo que sí tiene placeholder no se reporta.
- La heurística de tamaño puede elegir el elemento equivocado. Buscar hacia afuera y luego hacia adentro "el cuadradito" es una conjetura. Puede aterrizar en un contenedor, en una etiqueta o en el hijo decorado equivocado — y entonces mide los colores equivocados. El límite de tamaño superior conviene revisarlo dos veces en sliders y barras de progreso anchos.
- "Tiene un borde visible" es la forma de reconocer la caja. Un control dibujado solo con un color de fondo, solo con una sombra, o con borde en un único lado, puede no localizarse correctamente.
- Las imágenes y los gradientes de fondo la derrotan. Cuando la herramienta se topa con una imagen de fondo mientras busca el color de fondo real, renuncia a un valor exacto y el veredicto se vuelve menos fiable.
- Se inclina a dar por bueno. Como toma el mejor de varias comparaciones y concede varias segundas oportunidades antes de fallar, algunos fallos genuinos en el límite se escapan. De esta revisión hay que esperar más issues perdidos que falsas alarmas.
- Solo el estado con el que carga la página. La herramienta no hace clic, ni pasa el cursor, ni enfoca nada — el contraste en hover y en foco son revisiones aparte. Un checkbox se evalúa como marcado solo si ya llega marcado.
- Solo lo que existe y está visible ahora mismo — no se llega a los controles dentro de acordeones, pestañas o modales cerrados.
- Las omisiones son silenciosas. Cuando un control no se puede localizar, o un color no se puede determinar, se omite en silencio en lugar de reportarse como "no se pudo revisar". Así que "no se encontraron problemas" no significa estrictamente "se revisó todo".
Dos puntos por confirmar
- Si la regla de que una barra de progreso queda exenta cuando la misma información está disponible como texto se aplica aquí. Esa exención por texto se confirmó para desplegables y campos de texto, pero no para barras de progreso ni sliders. Merece una verificación dirigida.
- Si el límite de tamaño superior está filtrando en la práctica barras de progreso y sliders anchos en páginas reales. La regla existe sin duda; que llegue a aplicarse depende de las dimensiones reales de cada página.
Referencia WCAG
Criterio de conformidad 1.4.11 Contraste no textual (Nivel AA)